Ben Hutchings writes:

You are missing the point - debian/source/format allows you to make it explicit that the source format is 1.0, if you want to stick with that.

You are missing the point - the planned switch of the default format isn't considered a good approach by quite some people. If something new gets introduced, switching to it should be done in wake manner. Other tools do that too, so why can't a central package as dpkg use that approach? I especially want to mention that a point release update for stable was required to get it working in stable like it should.

A while ago Ganneff wondered weather it would be possible to make the matcher extension of rxvt-unicode also pick up something like #12345 and turn it into a link into the BTS. It isn't or rather, it wasn't. The idea got stuck in my head and invested some time to make it happen. Here is the quick'n'dirty diff to make it happen:

--- /usr/lib/urxvt/perl/matcher.distrib	2009-11-30 06:44:07.000000000 +0100
+++ /usr/lib/urxvt/perl/matcher.rhonda	2010-03-24 23:57:01.000000000 +0100
@@ -3,13 +3,14 @@
 # Author: Tim Pope <rxvt-unicodeNOSPAM@tpope.info>
 
 my $url =
-   qr 
+   qr (?:
       (?:https?:// ftp:// news:// mailto: file:// \bwww\.)
       [a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*
       (
          \([a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*\)  # Allow a pair of matched parentheses
          [a-zA-Z0-9\-\@;\/?:&=%\$_+*~]  # exclude some trailing characters (heuristic)
       )+
+      ) \#[0-9] 4, 
     x;
 
 sub on_user_command  
@@ -145,6 +146,7 @@
          my @begin = @-;
          my @end = @+;
          if (!defined($col)   ($-[0] <= $col && $+[0] >= $col))  
+            $match =~ s/^#/http:\/\/bugs.debian.org\//;
             if ($launcher !~ /\$/)  
                return ($launcher,$match);
               else  

The diff is intentionally small so it is clear what is happening here. And it should give ideas for other extensions that one would like to make. I don't consider it though flexible enough to submit it upstream. Enjoy anyway!

A while ago I blogged about squashing release-critical bugs in stable. Yesterday we have reached a big milestone on that area: The amount of release-critical bugs in stable dropped below 1000 (blue graph). This might sound like it's still pretty high but given that we were well over 1600 RC bugs in stable a while ago I consider this quite a success. This is though no time for rest. There is still way too many RC bugs in stable, there are definitely still a lot of bugs that just aren't affecting stable and thus can be marked as such meaning no upload needs to get done for them. I'm taking a close look at those with higher numbers and most of those seem to be validly affecting stable too so they might require a bit more work than just tagging them. Thanks to all people who helped on that area, I can just remember a few names and don't want to make anyone else also working on stable to feel singled out, though I want to thank Lucas for tagging his FTBFS rounds with squeeze sid right from the start because the packages obviously have built before due to his regular rebuilds. Thanks to all, but like said, not the time to rest. The green squeeze graph is still around 250 bugs away from us!

The t-prot package might need your help: There is a discussion going on with the upstream developer how to proceed with respect to a hopefully helpful change in its behavior. There are several options how to address this, one of them would involve using the Getopt::Long module instead of Getopt::Mixed. Given that the benchmarks of upstream rather speak for sticking with Getopt::Mixed we would like to ask you for help: Please test this version of t-prot (for your safety: detached gpg signature for the version) and compare it to the packaged version 2.15 that I just upload into unstable (it is installable without anything else also into (old)stable or testing). Your feedback on this is truly appreciated, please send it until the start of next week (Monday evening/Tuesday morning) to "t-prot (AT) tolot.escape.de". Much thanks in advance!

On Wednesday I got DAM approval and since Saturday late evening I m officially a Debian Developer. Yay! :-) My thanks go to

• Christoph Berg (Myon) whom I know for more than a decade since we studied together, and who s career in Debian was way faster than mine, but who on the other hand probably knows me better than nobody else in Debian which made him the perfect advocate;
• Bernd Zeimetz (bzed) whom I know from my times at DaLUG and who was the friendliest Application Manager I could imagine he s probably also one of the fastest (8 days from application to AM report :-);
• Luca Capello (gismo), who was the most demanding but also most inspiring sponsor I ever had and who became a very good friend after we found each other over my package conkeror.
• Arne Wichmann (Y_Plentyn) for being my first drop-in center for Debian questions (like can I directly dist-upgrade from 2.0 to 3.0? :-);
• Martin Zobel-Helas (zobel) who was always encouraging me to continue exploring new sides of Debian;
• Gerfried Fuchs (Rhonda) just for being there (and for being a package maintainer with good relations to upstream ;-);
• my coworkers at the IT Services Group of the Department of Physics at ETH Zurich, who always found new challenges in Debian for me to solve;
• and all those others who offered to also advocate me (e.g. Otavio Salvador) or sponsored my packages so far (or at least offered to do so), e.g. Alexander Wirt (formorer), Martin F. Krafft (madduck), Robert J rdens (jordens),

As Bernd cited in his AM report, my earliest activity within the Debian community I can remember was organising the Debian booth at LinuxDay.lu 2003, where I installed Debian 3.0 Woody on my Hamilton Hamstation hy (a Sun SparcStation 4 clone). I wrote my first bugreport in November 2004 (#283365), probably during the Sarge BSP in Frankfurt. And my first Debian package was wikipedia2text, starting to package it August 2005 (ITP #325417). My only earlier documented interest in the Debian community is subscribing to the lists debian-apache@l.d.o and debian-emacsen@l.d.o in June 2002. I though remember that I started playing around with Debian 2.0 Hamm, skipping 2.1 (for whatever reasons, I can t remember), using 2.2 quite regularily and started to dive into with Woody which also ran on my first ThinkPad bijou . I installed it over WLAN with just a boot floppy at the Chemnitzer Linux-Tage. :-) Anyway, this has led to what it had to lead to a new Debian Developer. :-) The first package I uploaded with my newly granted rights was a new conkeror snapshot. This version should work out of the box on Ubuntu again, so that conkeror in Ubuntu should not lag that much behind Debian Sid anymore. In other News Since Wednesday I own a Nokia N900 and use it as my primary mobile phone now. Although it s not as free as the OpenMoko (see two other recent posts by Lucas Nussbaum and by Tollef Fog Heen on Planet Debian) it s definitely what I hoped the OpenMoko will once become. And even if I can t run Debian natively on the N900 (yet), it at least has a Debian chroot on it. :-) A few weeks ago, I took over the organisation of this year s Debian booth at FOSDEM from Wouter Verhelst who s busy enough with FOSDEM organisation itself. Last Monday the organiser of the BSD DevRoom at FOSDEM asked on #mirbsd for talk suggestions and they somehow talked me into giving a talk about Debian GNU/kFreeBSD. The slides should show up during the next days on my Debian GNU/kFreeBSD talks page. I hope, I ll survive that talk despite giving more or less a talk saying Jehova! . ;-) What a week.

<comment />

Your Expectations
I won't fulfil them for you
they are only yours Feeling been let down
it is understandable
but it's also wrong There are more than me
who can do the piece of work
why just bug me then? Effect is stop work
so that others won't expect
your problem is solved

German Version If you are looking for some packages to take care of within Debian, take a look at this list and feel free to contact me if you are interested.

This poem is only in German language, but I hope you can forgive me to run it in my English language feed nevertheless. I send you the best season greetings, have a nice time, use it well, relax and think about it. :)

Weihnachtsgedicht 2009

Vor ungef hr zweitausend Jahren
glaubt man, wurde ein Mann geboren
glaubt man, dass es Gottes Sohn gewesen ist
glaubt man, der uns alle erl sen sollte

Irgendwann sp ter
dachte man, das w re ein Grund, daran zu denken
dachte man, es w re ein Grund, in sich zu kehren
dachte man, es w re eine besinnliche Zeit

Heute jedoch
stresst man, um nur ja Geschenke f r alle zu finden
stresst man, weil jeder berall mit einem feiern will
stresst man, um sich besonders g tig zu zeigen

Ich w nsche mir, dass
wir helfen, uns zur ck zu erinnern
wir helfen, uns zur ck zu besinnen
wir helfen, wieder ruhiger zu werden

Ich w nsche euch ein erl stes, besinnliches,
g tiges und ruhiges Weihnachtsfest!

Others are doing it, so I thought I'd join in, too. Though, from a different perspective. Often enough people claim that package maintainers don't seem to care about their packages anymore once they did hit stable because they say it isn't as easy to update packages in stable. While this is partly true it still doesn't send a too good impression to have a high and increasing release-critical bug count for stable. UDD makes it easy. It has a field affects_stable in its bugs table, and the view bugs_rt_affects_stable is even yet better. I fiddled together two short statements that help me to find release-critical bugs for stable:

SELECT b.id FROM bugs_rt_affects_stable bas
   LEFT JOIN bugs b ON bas.id=b.id
   WHERE b.severity IN ('serious', 'critical', 'grave')
   AND b.id NOT IN (select bau.id from bugs_rt_affects_unstable bau)
   ORDER BY b.id;

The second statement is without the AND clause to see all open release-critical bugs. Going through this list isn't too complicated, and I already found a good rush of bugs to mark as not affecting stable because the reason for the bug only appeared after the lenny release. I could list their bugnumbers, but it's currently up to 39 such bugs since yesterday and I don't want to bore you with it, actually it didn't involve any touching of the package but it will definitely make it easier to find the real release-critical bugs that do affect stable and should get addressed in an update to it. Still lots to do, 39 bugs down isn't the world when the barrier is set to about 1500. Though, it's still more than 2% and this is something that makes me a bit happy.

• when people upload to Debian with an @ubuntu.com email address
• even better, if they do that when they are DDs (so with a @debian.org address)

Yeah! Actually, doing so shows several things: That the collaboration between Debian and Ubuntu actually works out. That people that feel more attached to Ubuntu also do care for Debian. And that those people started to realize that contributing things back to Debian actually does reduce their own workload with respect to not having to maintain seperate patches, with the benefit of all involved parties. So big kudos to you people being able to look over the corner of your little universe and see the bigger picture for the benefit of all!

It is great to see that the collaboration between Debian and Ubuntu is improving; and I don't say that just because it probably can't be much better within the Debian/Ubuntu Games Team, we have people from both distributions working inside the team and most of the packages don't carry Ubuntu specific patches (anymore) because of that. Actually, seeing that things do go pretty well in that area made me consider signing up to become a MOTU. To do that one has to sign the Ubuntu Code of Conduct (CoC) which is a fairly good document, actually. I wish there would be something similar within Debian that is considered binding, it would be able to reduce quite some tough and rough times, actually. It is about and explains to be considerate, be respectful, be collaborative, what to do when you disagree, when you are unsure and wants you to step down considerately. If these principles would be carried out amongst all the free software communities (and I really mean carried out and not just be there and grow old) I expect it would be much more welcoming for new people. And it's not too hard to do your part for it (... says the person who just recently had to excuse for her behavior). Anyway, there is this one part with the CoC that itches me. It's not that one has to sign it with their GnuPG key, but related to it. Making it a requirement to sign it gives the document a much more official character, actually gives it the feeling and impression of a contract and I expect it is meant to carry that feeling. Though, there is this one part in it that I consider off for such a document:

Nobody knows everything, and nobody is expected to be perfect in the Ubuntu community (except of course the SABDFL).

Given that the acronym SABDFL refers to Mark Shuttleworth it means that one has to expect him to be impeccable which I am sorry but cannot sign. I don't expect that from anyone else but myself, even Mark is only human and can make mistakes. Even though it's obvious that this is a tongue-in-cheek kind of joke which might be meant to make it clear that the Ubuntu community isn't just sterile having this in a document that is expected to get signed by contributors is just an extremely bad idea. Sorry, Ubuntu, as long as this joke is part of the CoC I can't sign it with clean conscience, no matter how much I would sign the rest of it a thousands' time. It really makes me wonder how many others actually did read the "contract" carefully that they are signing but on the other hand simply didn't care. There is too many site signup stuff out there that noone reads neither.

In my last blog entry I used the term "image-hack". It seems like it has been considered to have a negative feeling attached to it. Even though I consider this very amusing in a community that likes to pride itself with the term "hackers" I guess I can understand why people consider it a negative term. Even though technically a mockup of a website in image form actually feels just a crude hack it wasn't meant to belittle what pixelgirl has produced. Her image-hack looks extremely well. Unfortunately no further contact after the debconf was established and personally I'm not convinced how the tiny image would work for other pages besides the start page and removing the DSAs and News from the start page is a no-go, we actually do receive positive feedback for that. So it is what it is, an image-hack. An extremely well done one, but still just that.

Like written in a former blog entry I am working on preparing for getting Kalle's Debian Redesign tested and installed. Even though some unfortunate events happened which made me reconsider my efforts and a lot of things changed for me I am still up with the effort. Mostly because I didn't became part of the webmasters just to chicken away in the face of obstacles, and also not just because yet another image-hack did pop up that neither showed anything usable or overall-thoughts or actual code/concepts or even tried to get in contact with the webteam. I only remember to have received positive feedback in which I also include minor change suggestions like that the exact hits and other hits sections in the packages site aren't as clearly distinguishable as before. I have of course forwarded these to Kalle and we are looking for a solution that would go with the style. Speaking of the packages site I finally managed to get the packages from the main pool displayed too so it shouldn't behave differently to the old one anymore in that respect (see e.g. wesnoth for some more distributed package). The next step I finished these last days was setting up a testsite for www as you can find it on www.deb.at. Please notice that you might want to surf that site in English (either change your Accept-Language settings or click on the English links at the bottom of the pages) because some of the changes are only recognizable there; like, the main page in other languages look immensely different. Where to go from here? Kalle also has proposal for the BugTracking System and the Planet so that targets are the obvious next steps. I can't tell yet when they will be done, depends on how complicated it is to set up an environment for it, but I will keep you updated.

Since I returned from this year's debconf quite a lot things have changed in my life. One thing I knew way before debconf already, I switched jobs. I was working for a pretty long time (and also through great times) for Silver Server, for well over 6 years. Let's see what I can do in and for my new job. I'm still only pretty short there yet and I being to understand what's going on (and what could need improvements in some workflows) but it's too early to see that more precisely. On a small side-note, the job change also required me to switch my mobile phone number because the old one was a company's number. I now have a private one that I don't fear of losing anymore. If you subtract the number 3933309527644 from my old one you have my new one. On the other hand you can always ask me for it in case you had my old one and wonder. ;) Besides my mobile phone number other smaller things have changed over time too. Most of you noticed that I'm neither using my @ist.org nor my @debian.org address anymore because they did carry the wrong nick. And given that everyone was switching their gnupg keys I did so too. Like before I again created separate keys for private usage and for Debian usage. I'm not really following the procedure of sending out signing requests to people who have signed my old key(s), personally I don't follow them myself so I don't expect others to do. They are though cross-signed with the old ones just to be on the save side to keep the WoT not losing connections. Also I finally got around to set up my own ejabberd server and did create my a new jabber ID that I also plan to keep. It is the same as my private mailaddress as you can see linked above in the key for private usage. ;) One of the reasons for the server is by the way also a testbed for the packaging of ejabberd which will get moved into team maintenance with the next upload which will be the next upstream version, 2.1. But the biggest and most important change in my life is that I will have to rethink my spare time spending quite a lot because there will be something demanding a lot of time starting in about march next year. An extremely fortunate change and almost as happy one even though it means that I won't be able to attend next year's debconf in NY, but I hope the people whom I told that I will be there aren't too disappointed by this announcement. Sorry! :)

It's quite interesting. Twitter has this snippet in its registration page: By clicking on 'Create my account' above, you confirm that you are over 13 years of age and accept the Terms of Service. At least currently when you click it leads you to a page that says: Something is technically wrong. I'm very happy to accept that, but I have this strange feeling that it's not what they intended to have there...

It's always enlightning how some people see how Debian works. Or not. It seems to get more and more common that instead of filing a bugreport people seem to consider it appropriate to rather rant in their blogs about it. That will definitely get things fixed and done and motivates everyone involved to work on the issues that they get notified about only through third-party. And of course it's absolutely alright to change an application directly, not use dpkg-divert or similar, and then complain wildly about how unfair an upgrade of the package replaced that file. And, Andrew, there wasn't a DSA about CVE-2008-2236 because it was considered a too minor issue for that. Thanks for the fish. Did you btw. try the version from the upcoming lenny release? It's not like it's not directly installable in etch because of dependencies... Only once I would hope that people that are that deeply involved in Debian (like, being Debian Developers or long-time contributors) would do things like random users do: File the things they are annoyed with, even if they are as minor and awkward as some of the bugreports I receive for wesnoth.

I dedicate this oldie but goldie to all the people in Debian that enjoy discussing everything to a dead end and then claim to have won because noone responds anymore because there is no sense to do so: Du vastehst mi ned ("you don't understand me")

Since last weekend backports.org has two more services supporting tracking of what's going on. I will list them in chronological order: Tracking of Security issues in backports packages: This was one of the many topics that was discussed at the Security Team meeting in Essen at the end of last month and Florian Weimer implemented a first version of tracking security issues within backports.org. It currently compares the backported version against the one fixed for unstable, so at the moment it still has some false-positives (e.g. libspf2 because the fix was taken from lenny-security), but this is still a big step forward and helpful to track outstanding issues here, too. Diffs between etch-backports and lenny: Something similar was available at some other places before but strangely got discontinued. In here you can see which packages in backports are older (meaning only debian revision difference), outdated (newer upstream version in lenny) newer (backported from unstable?), have a wrong version schema or are not available in lenny (propably even removed from unstable). It will hopefully help people to get their backports in sync. At least it's an indicator of how well the packages are tracked. Hope you consider them already as useful as myself, even though there is obvious space for improvements. But they are both quite helpful already in their current state so that shouldn't hinder you from using them. :)

For a long time publishing source code under a freedom giving license was considered bad. What if people would take your code and reuse it? What if you don't like how they reuse it? History has shown that this has happened in only rare cases. And even then, having your code reused is an homage towards your creation. People started to understand that and it gladly became very common practise. But it seems like the story starts over from the very beginning again, the field though is a different one. It's now graphic artists and especially musicians who are facing the same fears this time. But I think, it shouldn't be me writing this because I'm neither (well, only very few people consider ASCII art as proper art. Probably even less than consider good code to be art..). Good thing is, I don't have to. One of the wesnoth graphic artists did it, and way better than I would ever be able to get the idea across. So here you go: Jetryl about GPL Policy in wesnoth. It might be long, but it's definitely worth the read, and I hope it will help to make some people understand better and fear less.

Wow, don't even remotely remember anymore when I was last blogging about going to the cinema. Granted, I wasn't that often in recent times, but I haven't mentioned some movies... Whatever. Yesteday I have been to cinema again, and we watched "The Dark Knight". To be honest, I regret to have gone. The movie is as dark in its setting as the title says, even darker than what was common in previous Batman movies. They turned Batman into James Bond style, turning Morgan Freeman into Q, and using cheap Eminem quotes. I feel sorry for Heath that this was his last movie to star in. Even his great performance wasn't able to save the movie, and it's sad that this should be the movie people will remember him with... You deserve better, buddy.

Last week I wondered how much space a complete git conversion would actually need—and I was quite surprised:

$ du -hs webwml*
325M    webwml
416M    webwml.git
819M    webwml.svn

The first line is the regular CVS checkout. The third line is the SVN checkout that's available from alioth. You can see that the size is not really something one would want, especially since the real gain is extremely little: besides offline diff you rather have disadvantages with not being able to do much offline because anything history wise requires you to be online. In CVS you at least knew that revision 1.12 of a file is three commits above revision 1.9 of the same file; while in SVN you have no chance offline to know how many commits to a file happened between revision 512 and 1024, if any at all. The conversion to git took me quite a long time, practically almost three days of (non-constant) running git-cvsimport on my laptop. The time did not completely surprise me, at least when I noticed in the end that it were well over 83 thousand commits in well over 10 years, reaching back to July 1998. My first own commit was in July 2001, which wasn't too hard to find out with git neither, and required no online operation. git gives you complete offline access to the history. This is actually something that the build process can be based on. There propably will be some speed drawback with not being able to do simple-math for revision difference like in CVS, but that actually will have to be checked. I'm still convinced being able to do all the stuff offline without any strange hacks or needing to be online all the time is something worthwhile. Things left to do and which I propably won't find the time in the too near future because of ... erm, you know? Lenny? That we want to release? But anyway, to not have the list of things get lost, here is a (not complete) list of things in case you are bored and want to play around a bit:

• Adapt the various scripts to not check CVS revisions but use the sha1 sums.
• Adjust translation-check translation="" value for all files to use sha1 sums.
• Check wether a full website build would work after that changes.
• Try out how submodules work and wether they might be reasonable to use for language subdirectories to allow translators partial checkouts.
• ... other things I've forgotten but that could be added to the WebsiteVCSEvalutaion wiki page.

Playing around a bit? Well, you don't have to do the whole git-cvsimport on yourself: I've pushed my webwml.git repository to alioth: "git clone ssh://git.debian.org/git/users/alfie/webwml.git" should get you started. Please notice to play around in a seperate branch and not directly in origin to be able to pull further and update from time to time.